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ABSTRACT 



A method uses a plurality of hash tables to provide an object 
repository for object oriented application development and 
use. The method includes storing an object identifier and a 
representation of the object in a first hash table and storing 
data about the object and the object identifier in a plurality 
of paired hash tables with the hash tables organized in 
mirrored table pairs. The data about the object include an 
object's class name, object methods, return types, and the 
data values returned by object methods. The non-inverse 
hash tables of the mirrored table pairs support fuzzy 
searches for objects while the inverse hash tables of the 
mirrored table pairs support searches for objects by object 
identifier. A system that implements the inventive method 
includes a first hash table for storage of data representing the 
object with an object identifier used as a key for storage of 
the representing data and a plurality of mirrored table pairs 
for the storage of data about objects. In the non-inverse table 
of the mirrored table pairs, the data about the objects are 
used as keys to store an object identifier. In the inverse tables 
of the mirrored table pairs, the object identifier is used as the 
key for storage of the data about the data objects. The 
mirrored table pairs and hash table provide an efficient and 
economical object repository. Such an object repository may 
be provided with a computer application at a nominal 
expense. Thus, object oriented applications may be devel- 
oped without regard for whether the end user system 
includes an object repository. 

9 Claims, 7 Drawing Sheets 
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HASH TABLE IMPLEMENTATION OF AN 
OBJECT REPOSITORY 

FIELD OF THE INVENTION 

This invention relates to database systems, and more 
particularly, to database systems utilized for storage of 
objects implemented in an object oriented programming 
language, 

BACKGROUND OF THE INVENTION 

Object oriented programming languages are well known. 
The most popular object oriented language is C++; however, 
the JAVA programming language is rapidly gaining accep- 
tance. JAVA is an interpreted language that is especially 
adapted for open network environments where the client/ 
server architecture is widely used. One major advantage of 
JAVA is its capability to be compiled once and then executed 
on computers having different hardware and software con- 
figurations. That is, a JAVA application program does not 
require information regarding the configuration of the 
machine on which it will run for its compilation and execu- 
tion. 

Most application programs operate on data. Frequently 
this data is stored in a database that is separate from the 
application space where the application program is execut- 
ing. The management of data within the database and the 
retrieval and storage of data in response to queries and write 
commands from application programs are typically per- 
formed by a database management system. Prior to the 
advent of object orienting programming, relational data- 
bases and relational database management systems were the 
most frequently used storage repositories for application 
programs. As object oriented programming became more 
prevalent, interfaces were developed that converted objects 
received from object oriented implemented applications into 
data structures that could be stored within a relational 
database system. However, a number of inefficiencies are 
encountered with the use of relational databases to store 
objects. One limitation of relational databases that results in 
the inefficient storage of objects is the primary data organi- 
zation form used by relational databases, namely, data 
tables. Objects are efficiently stored in relational databases 
because they typically have a one to many relationship that 
is best represented by a binary tree structure. Binary tree 
structures are implemented by one or more join operations 
across tables in a relational database and these operations 
require overhead processing by the relational database man- 
agement system. To overcome these limitations, object 
repositories for the storage of objects and object repository 
management systems were developed. These object reposi- 
tories and management systems do not depend upon join 
operations across data tables for storage of objects. Object 
repositories permit objects processed by object oriented 
implemented programs to be created, removed, retrieved or 
updated with programming statements placed within the 
object oriented application program. 

No standards exist for object repositories. That is, each 
object repository management system has its own command 
syntax and commands that are supported by the object 
repository management system. Thus, application programs 
incorporate commands to the object repository management 
system that comply with these syntactical restraints and 
utilize the commands supported by the management system. 
If a different object repository is used or the application 
program is transported to a computer using a different object 
repository, the repository command lines in the program that 
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interact with the database must be revised and the program 
recompiled. Consequently, changing the database system or 
transporting the compiled program to a computer using a 
different database system directly impacts the usefulness of 

5 the program. For JAVA applications, this effect negates a 
major advantage, namely, the ability to compile an applica- 
tion once and use it on different computers regardless of 
platform configuration. 

Known object repositories not only are controlled by 

10 proprietary interfaces as described above, but they also 
include complex data structures that are typically proprietary 
as well. Additionally, known object repositories are rather 
expensive. If a software developer develops a computer 
application that is designed to store objects in an object 

15 repository, then a potential purchaser of the application must 
either already have a computer system that uses the object 
repository or the customer must purchase and install the 
object repository with which the computer application inter- 
faces. This additional investment may reduce the market for 

20 the computer application and sales of the application pro- 
gram may suffer as a result. 

What is needed is an efficient implementation of an object 
repository that can be provided with object oriented com- 
puter applications without adversely impacting the scope of 

25 the environment in which the application may be used. 

SUMMARY OF THE INVENTION 

The limitations of previously known object repository 

30 management systems are overcome by a system and method 
performed in accordance with the principles of the present 
invention. The method of the present invention includes 
storing an object identifier and a representation of the object 
in a first hash table and storing data about the object and the 

35 object identifier in a plurality of paired hash tables with the 
hash tables organized in mirrored table pairs for storage of 
the object. The data about the object include an object's class 
name, object methods, return types, and the data values 
returned by object methods. The non-inverse hash tables of 

40 the mirrored table pairs support fuzzy searches for objects 
while the inverse hash tables of the mirrored table pairs 
support searches for objects by object identifier. 

Preferably, the method of the present invention stores an 
object by generating an object identifier for an object and 

45 then reflecting the object to determine the object's class 
name, the methods for the named object class, the return 
types for the identified methods, and the data values returned 
by the identified methods. The object's class name, return 
types and methods are then stored in the non-inverse hash 

50 table of a mirrored table pair with the object's class name, 
return types and methods being used, respectively, as the key 
for storage of the object identifier in the non-inverse hash 
table of each hash table pair. In the inverse table of each 
mirrored pair, the object identifier is used as the key for 

55 storage of the object's class name, methods, return types and 
data values returned for the methods. Thus, each mirrored 
hash table pair is comprised of a non-inverse hash table and 
an inverse hash table with the key and data value relation- 
ship in the non-inverse table being reversed in the inverse 

60 table. For the mirrored hash table pairs storing the class 
names, methods and return types, the object's class name, 
methods, and return types are used as a keys to store the 
object identifier in the non-inverse table of each mirrored 
table pair while the object identifier is used as the key to 

65 store the object's class name, methods, and return types in 
the inverse table of each mirrored table pair. For the mir- 
rored hash table pair storing the data values returned by 
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methods, the object's class name and methods are, communications between the application program and 

preferably, concatenated to each data value to more uniquely object repository of FIG. 1; 

define the data value. The concatenated data value is used as FIG. 3 depicts exemplary programming statements for the 

a key to store the object identifier in the non-inverse table of gateway of the generic object repository interface of FIG. 1; 

a mirrored table pair while the object identifier is used as the 5 FIG. 4 is a diagram of data structures used in the object 

key to store the concatenated data value in the inverse table repository of the present invention; 

of the mirrored table pair. FIG. 5 depicts exemplary programming statements for 

For storage of the data representing the object itself, query arguments shown in FIG, 3; 

which may be conceptualized as an array of byte data in FIG 6 h a flowchart depicting the steps of an exemplary 

memory, the data is first serialized by converting the object 1Q process operating in accordance with the principles of the 

data to string data. The object identifier is then used as the present invention; and 

key to store the serialized data string in a hash table. No FIG. 7 is a block diagram of the interface to the object 

inverse table is associated with the hash table as the serial- repository shown in FIG. 1. 
ized object data string is not an efficient key for storage of 

the object identifier. 1S DETAILED DESCRIPTION OF THE 

. 15 INVENTION 
An object may be retrieved from the object repository 

implemented by this method by submitting an object iden- A system that utilizes the object repository of the present 

tifier to the database management system for the repository. invention is shown in FIG. 1. Application space 10 is the 

The database management system uses the object identifier memorv of a colter system usually under the control of 

to retrieve from the hash table having no inverse table, the M an operating system in which application programs and 

serialized data string. This data is then used to inflate the su PP 0 ^ng utility programs are executed. In FIG. 1, appli- 

object for delivery to an application. The object data is "V? A n P?&™ 14 15 aD ^object-oriented program, such as a 

* • * n • j . n . A i_ j . JAVA class program. Application program 14 generates 

retrieved from the hash table and is used to inflate the data objects for ^ m ^ h * \ s . Application 14 

object. Fuzzy search queries may be issued by an application may also retrieve objects from object repository 18 05ject 

program and are supported by the mirrored table pairs. 25 repos itory 18 includes a database management system that 

Fuzzy searches look for object's class names, return types implements commands for accessing data stored with object 

and/or methods that correspond to specified range param- repository 18 and for storing data within object repository 

eters or boolean values. For all non-inverse table keys that 18. These commands are used by interface 20 to manipulate 

lie within the specified range or having matching boolean objects in a manner described in more detail below. Invoking 

values, the object identifiers are retrieved. An array of these 30 instances of objects that implement interface 20 in the object 

object identifiers may then be returned to the application oriented programming language statements of computer 

program that issued the fuzzy search query for further application 14, application program 14 may store and 

processing. retrieve objects in object repository 18. 

A system that implements the method of the present An interface 20 may be used to define communication 
invention includes a first hash table for storage of data 35 with object repository 18. By including programming lan- 
representing the object with an object identifier used as a key guage statements in the main portion of application program 
for storage of the representing data and a plurality of 14, application program 14 may cause the operating system 
mirrored table pairs for the storage of data about objects. In to create an instance of an interface program 20 for com- 
the non-inverse table of the mirrored table pairs, the data munication with object repository 18. These programming 
about the objects are used as keys to store an object 40 statements may include arguments and a reference to a 
identifier. In the inverse tables of the mirrored table pairs, the configuration file for generation of the implementation of the 
object identifier is used as the key for storage of the data generic database interface such as directory information and 
about the data objects. The mirrored table pairs support the like. The configuration file includes statements and data 
fuzzy search queries. defining the proprietary specifics of the object repository 

The mirrored table pairs and hash table of the present 45 that is constructed in accordance with the principles of the 

invention provide an efficient and economical object reposi- present invention. At runtime, the operating system pro- 

tory. Such an object repository may be provided with a grammatically generates the data structures for the imple- 

computer application at a nominal expense. Thus, object mentation or instance of interface 20. The instance of the 

oriented applications may be developed without regard for interface created by the operating system thereafter supports 

whether the end user system includes an object repository. 50 communication between application program 14 and object 

These and other advantages and benefits of the present repository 18. 

invention may be ascertained from the detailed description One parameter for interface 20 that may be defined by a 

of the invention presented below and the drawings discussed configuration file at application runtime is the maximum 

therein. number of threads between a particular instance of interface 

DETAILED DESCRIPTION OF THE DRAWINGS 55 20 and ° bj f Ct re P ositor y 18 A f?f f a communication 

process between an mstance of interface 20 and object 

The accompanying drawings, which are incorporated and repository 18 while a gateway is a communication process 

constitute a part of the specification, illustrate embodiments opened between an application program and an instance of 

of the present invention and, together with a general descrip- interface 20. A thread is sometimes denoted by the term 

tion given above and the detailed description of the embodi- 60 "connection." A thread implements communication with an 

ments given below, serve to explain the principles of the object repository in its proprietary language. An application 

present invention. program may generate multiple gateways to an instance of 

FIG. 1 is a system overview of a computer executing an interface 20 or multiple application programs may each have 

application program that communicates with an object one or more gateways to interface 20. Typically, a thread is 

repository through an interface; 65 allocated to each gateway until the maximum number of 

FIG. 2 depicts exemplary programming statements for threads is reached. Thereafter, threads are shared by gate- 
creating an instance of a generic interface for supporting ways. 



06/23/2003, EAST version: 1.04.0000 



6,154,747 

5 6 

One parameter which may be defined by a configuration application program 14 supported by the gateway definition 

file is the length of time that an object may be stored in an shown in FIG. 3 are: SUBMIT object, GET object, GET 

object repository. This parameter is of particular importance update object, UPDATE object, REMOVE object, and 

for servers that support communication sessions over an QUERY for objects. SUBMIT object is used by an appli- 

open network, such as the Internet. Such servers communi- 5 cation program 14 to store an object in object repository 18. 

cate with a plurality of client applications that may only The argument new_object is the particular instance of a 

require storage of objects in the repository coupled to the object. GET object retrieves an object from object repository 

server for a short amount of time. As communication ses- 1** and its argument OID is a string identifier for an object, 

sions do not require a continuous communication link, a String identifier OID is discussed in more detail below. GET 

client program may end a session without communicating an 10 u P date ob j cct retrieves a C0 Py of an ob J ect m an u P date 

end of the session. This scenario demonstrates one reason wrapper that may be altered by an application pro- 

there is a need to expunge objects from an object repository. ?r am : fi ^ 1 a ^ gu ^? ent f ° r , thi f . °P e ' ation * also f a s f rin S 

When an instance of interface 20 is activated, the length of identifier OID The update object has a time of retrieval 

time for object storage, if defined in the configuration file for associa * d wth . 1 • ^ t an UPDAFE <? ata °j* ™ 

. - *u • « c • * -r %a * ■ * occurs, the update object wrapper is the argument for the 

interface 20, causes the instance of interface 20 to interro- 35 X ion. ^ of ^ mterface | Q yerifies ^ 

gate the object identifiers for those objects ^stored m reposi- ^ repository 18 that the data object stored ^ the 

tory 20 and determine the time of storage of the object. If the repository that corresponds with the OID for the object in the 

object has been stored for a period of time exceeding the updale wrapper being submitted has not changed since the 

defined storage time length, the object is deleted from the retrieved time associated with the update wrapper. If the 

repository. Each instance of interface 20 preferably gener- 2 o stored object has changed, the object__has__changed excep- 

ates an internal thread to the repository management system tion is returned to application program 14. Otherwise, the 

for the delivery of "delete object" commands if timed new contents of the object replace the previous content for 

storage is implemented. the object stored in object repository 18. REMOVE object 

An exemplary high level structure of a definition of an has an OID string identifier as an argument and it results in 

interface 20 is shown in FIG. 2. The programming state- 25 the storage space for the corresponding object in object 

ments shown in FIG. 2 define high level operations for repository 18 to be made available for other object data 

interface 20 that may be used by an application 14. Pro- storage. These commands are object transactions that are 

gramming statement 36 defines the normalization operation implemented by an instance of the defined gateway, 

that verifies the indexing of object repository 18 is not A preferred structure for object repository 18 that may be 

corrupted. If the repository indexing is corrupted, the nor- 30 accessed by an instance of the gateway depicted in FIG. 3 is 

malization exception is generated and exception processing shown in FIG. 4. Object repository 18 includes a single hash 

occurs in application 14 to resolve the index corruption, if table 62 and hash table pairs 64, 68, 72, and 74 which are 

possible. Programming statement 40 creates an instance of organized in mirrored table pairs. Each mirrored table pair is 

interface 20 to be used by an application program 14. comprised of a non-inverse hash table and an inverse hash 

Exception processing in application 14 handles the message 35 table. The inverse tables are so referenced because they 

that the operating system cannot create an instance of reverse the key/value organization of the non-inverse hash 

interface 20. Programming statement 44 is a request for tables. Mirrored table pair 64 stores class names for objects, 

generation of a gateway for communication between an Mirrored table pair 68 stores data regarding the methods 

application 14 and a created instance of interface 20 to used by the objects stored in repository 18 and mirrored 

process an object repository operation. If the object reposi- 40 table pair 72 stores data regarding return types for the 

tory is closed, an exception is generated and processed by methods of the objects stored in repository 18. Mirrored 

application 14. Generation of a gateway causes a thread for table pair 74 is used to store data values returned by the 

communication between an instance of interface 20 and methods for objects stored in repository 18. Hash table 62 is 

object repository 18 to be assigned to the gateway. Program- organized to store object data using an object identifier as a 

ming statement 46 opens storage within object repository 18 45 key. Preferably, the database used to implement the hash 

and provides the security parameters for reducing the like- tables of repository 18 generate the key for storing infor- 

lihood that another instance of interface 20 accesses the mation in a hash table by providing an object identifier 

portion of object repository 18 being allocated for this (OID) as an argument to a hashing function. The value 

particular instance of interface 20. Exceptions to this opera- generated by the hashing function is used as a key for storing 

tion indicate indexing in the repository is corrupted or that 50 data in a hash table. Because use of serialized data object 

no interface instance has been created. Programming state- data would not be efficiently hashed to generate a key, the 

ment 50 defines the closing operation for an application hash table used to store object data does not have a corre- 

program 14. Closing object repository 18 terminates the sponding inverse table. Instead, an OID is used as a key to 

gateway to interface 20 and any corresponding threads, if the store object data in hash table 62 after the object data has 

threads are not being shared. The exception code to this 55 been serialized, that is, converted to string data. An object's 

operation indicates indexing is corrupted. Programming class name is stored in the non-inverse table 64a as the key 

statement 52 defines the operation for obtaining the identi- for the OID of the corresponding data object. Likewise, 

fier for a created instance of interface 20 for an application object methods are stored in non-inverse table 68a as the key 

program 14. These high level operations are implemented by for the OID of the corresponding object and the return types 

an instance of interface 20 that is invoked by an application 60 for the methods of the objects are stored in the non-inverse 

14. table 72a as the key for the OID of the corresponding object. 

Exemplary programming statements that define a gateway The data value returned by a method of an object is 

60 for object repository 18 are shown in FIG. 3. These concatenated with the object's class name and method to 

programming statements define exemplary interface com- generate a key that is used to store the OID in non-inverse 

mands that may be used by an application program 14 for 65 table 74a. In the inverse table of each of the mirrored table 

communication with object repository 18. The exemplary pairs, the OID is used as the key to store the data value that 

operations that an application programmer may use in an is the key for the OID in the non-inverse table. 
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Preferably, each hash table of object repository 18 is argument values an object's class, method and return type, 

implemented with a Berkeley DB database system available Preferably, a data value may be provided by submitting a 

from Sleepycat Software Inc. of Carlisle, Mass, and the null value for this argument value. This query causes an 

programming language statements that implement instances instance of interface 20 to retrieve the corresponding object 

of interface 20 communicate with the management system 5 from repository 18 and return it to application program 14. 

for the Berkeley DB through a thread extending to reposi- QUERY for OIDs has the same arguments as QUERY for 

tory 18. The Berkeley DB database uses union data struc- objects; however, it returns the object identifiers for those 

tures implemented in the C programming language. data objects corresponding to the arguments passed in the 

Preferably, one Berkeley DB is used for each of the nine command. 

hash tables required to implement the preferred structure 10 QUERY for object and QUERY for OID may also be 

discussed above. Eight of the Berkeley DBs are used for the passed a range query argument denoted as Palisade Query 

four mirrored table pairs and the other Berkeley DB is used pq m FIG, 3. Exemplary forms of PalisadeQuery PQ used 

for the single hash table in the preferred implementation. ^ tne preferred implementation of the present invention are 

Berkeley DBs may be configured for one of three access shown in FIG. 5. The first form of the argument results in the 

methods. These access methods are binary tree (mode 1), 15 generation of a query that searches object repository 18 for 

extended linear hash table (mode 2), and fixed or variable d a t a objects or data object identifiers that correspond to the 

length record (mode 3). Preferably, the Berkeley databases c i ass name, method, return type and similar data value 

are configured to operate in mode 2 for use as hash tables. specified in the PalisadeQuery PQ. The data value may 

The programming statements that implement interface 20 include wild card characters, such as to broaden the 

preferably include five (5) instances of a Java class with four 20 search. A false value for the Boolean operator "like" permits 

of the five class insurances controlling access to a mirrored the wild card character to be used as a literal character and 

table pair and the fifth instance of the class controlling DOt as a card character in a search string. The second 

access to the single hash table. The Berkeley DB preferably f orm causes all data objects to be retrieved or identified that 

used to implement repository 18 also includes a manage- correspond to the class name, method, and return type 

ment system that handles transactions, locking, logging, 25 p aS sed in the argument and that have a data value corre- 

shared memory caching and database recovery. In addition, sponding to the value and unitary operator specified in the 

Berkeley DB supports C, C++, Java and Perl application argument. For example, "AGE>42'\ is a query for all object 

programming interfaces. identifiers that have an AGE method that return integer type 

The solid lines from the non-inverse tables to the inverse data having a data value of 42 or greater. The third form is 

tables in each mirrored table pair of the preferred imple- 30 like the second form except it permits the data value used in 

mentation of the object repository shown in FIG. 4 indicate the search to be within a range, such as, "42<AGE<54 " The 

that the storage methods of an instance of the object used to fourth and fifth exemplary forms shown in FIG. 5 are similar 

access each mirrored hash table pair cause the reverse of the to the second and third forms, respectively, except they are 

data stored in the non-inverse table to be automatically restricted to date values. 

stored in the inverse table of the mirrored pair. In this 35 When application program 14 stores an object to reposi- 
manner, the data supporting a direct query using an object tory 18 using interface 20, it provides the object to an 
identifier is automatically stored and the application pro- instance of interface 20 using a SUBMIT object command, 
gram does not have to cause interface 20 to perform that Interface 20 then performs the exemplary process shown in 
operation. The dashed arrows are used to indicate the FIG. 6 to obtain and store data regarding the object. First, the 
methods in the object for repository access may be used to 40 process receives a command for an I/O operation (Block 
independently query the hash tables of a mirrored table pair. 10O) and determines whether the command is a store corn- 
Object identifiers are preferably generated by capturing mand or a query (Block 102). For a store command, inter- 
system time in milliseconds since a certain date in 1970 and face 20 generates an object identifier (OID) for the object 
concatenating that value with the number of objects pro- identified by the store command (Block 104). In the pre- 
cessed by the instance of interface 20 being used by an 45 ferred implementation of the present invention, the apphca- 
application 14. This object identifier (OID) is preferably tion programs are JAVA classes and the core library that 
generated in string form and is returned to application supports application programs written in Java is used to 
programs 14 as well as being used to store data in object implement instances of interface 20. Preferably, a software 
repository 18, However, in distributed environments, two tool of the Java class library is used to reflect the object so 
instances of interface 20 may have processed the same 50 the class name may be determined by interface 20 (Block 
number of data objects and may generate an object identifier 110). The language tool library for the language used to 
at the same time. Accordingly, both instances would gener- implement an instance of interface 20 is also used to inspect 
ate the same object identifier. As a result, the object identifier the methods and identify the return types for the class of the 
may be provided to the wrong instance of interface 20 for object delivered to it by application program 14. (Block 
retrieval of the object without detection or an attempt to 55 114). The data value returned for each method is also 
store different objects in the same repository with the same determined using the software tool library of the implement- 
OID may occur. To reduce the likelihood of this occurrence, ing language API and the data value is concatenated with the 
generation of the OID is performed as discussed above class name and method to generate a key for storage of the 
except a prefix string corresponding to the name of the OID in non-inverse table 74a. (Block 114). The access 
server on which an instance of interface 20 is executing is eo method of the object for repository access then incorporates 
concatenated to the OID. As instances of interface 20 likely the class name in a proprietary database language statement 
execute on different servers in a distributed environment, which is used to store the object identifier in non-inverse 
this method of OID generation addresses the remote likeli- table 64a of mirrored table pair 64 with the reflected class 
hood of the same OID being generated by different instances name being used as the key. The object identifier is then 
of interface 20. 65 automatically used as the index or key by the access method 
The exemplary object queries defined in FIG. 3 support for storing the class name in the inverse table 646 of 
queries in four formats. QUERY for object may have as an mirrored table pair 64. (Block 118). Similarly, the method 
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names, return types and concatenated data values are used as responds with objects (Block 152), serialized object data 

keys to store object identifiers in the non-inverse tables of received from repository 18 are then converted to object 

each mirrored pair and the object identifier is used as the key form (Block 154) and the object or objects are returned to 

to store the method names, the return types, and concat- application program 14 (Block 156). If object repository 18 

enated data values in the inverse table of each mirrored table 5 responds with object identifiers, these are returned to appli- 

pair. (Block 118). The data comprising the object are then cation 14 without conversion because object identifiers are 

serialized by an instance of interface 20 and the serialized not serialized (Block 156). Preferably, for JAVA class 

data are incorporated in proprietary database language state- applications, the object data from object repository 18 are 

ments for storage in hash table 62 (Block 122). Serialization returned using com.sleepycat.db.Dbt for reasons similar to 

of an object means the conversion of the data representing 10 those dxscussed above - 

the object to string data. Preferably, as the serialized data are An interface which may be used to implement the process 
assigned to variables that are used in the proprietary data- of ™- » shown in FIG. 7 An instance of interface 20 
base language statements to write data to hash table 62 using mcIudes a command parser 86, proprietary ^database lan- 
the obiect identifier as the kev (Block 124) ^ a S e g enerator 88 » a response evaluator 90, and a serial 
n . r . data converter 92. Command parser 86 determines whether 
Queries from application program 14 are processed by an is a command ^ a store or query co mma nd, generates an object 
instance of interface 20 with reference to the data tables ideatifier f or a data object identified by a command, and 
implementing object repository 18. For example, the argu- determines the method and class for an identified data 
ment values from a query statement may be used to generate object. Command parser 86 also provides object data to 
the proprietary language statements for the Berkeley DB ser i a i data converter 92 for serialization of object data, 
preferably used to implement object repository 18. Query is 20 Proprietary database language generator 88 incorporates 
used broadly here to mean those commands that require data extracted from arguments passed in a command by said 
access or retrieval of data from repository 18 to implement command parser, data generated by command parser 86, and 
commands. For example, the argument values shown in FIG. serialized object data from serial data converter 92 into 
3 may be mapped to proprietary database language state- proprietary database language statements for communica- 
ments to query repository 18 for object data stored in one or 25 tion to the database management system of object repository 
more of the hash tables shown in FIG. 4. Thus, a procedure 18. Response evaluator 90 determines whether data received 
which implements a database operation uses the values from a thread is profile data that is provided to proprietary 
associated with operation arguments to generate a propri- database language generator 88 for incorporation in propri- 
etary database language statement. The data returned may etary database language statements and stored in the object 
then be converted to object form for return to application 30 repository or data to be returned to application program 14. 
program 14 by known methods. The data regarding the Serial data converter 92 converts serialized object data to 
proprietary form of the database language supported by the object data form for communication via a gateway to 
database implementing object repository 18 may be main- application program 14. 

tained in a configuration file for interface 20. Thus, the In operation, a computer system is provided with an 
information required by interface 20 to support any propri- 35 object repository having mirrored table pairs for the storage 
etary database interface may be made available at runtime of object data except a single hash table is provided for 
by placing data regarding the proprietary database language storage of the hash key and an object identifier. For appli- 
used by the database implementing object repository 18 in a cation programs that use object repository 18 on the corn- 
configuration file. puter system, an application programmer includes program- 
An exemplary process for implementing queries is shown 40 ming statements in the main portion of an application 
as part of the process in FIG. 6. The process first determines program to request generation of an instance of database 
whether the query identifies an object identifier (Block 140). interface 20. If the application program is executing on the 
If it does, the object identifier is incorporated in a proprietary same process computer to which object repository 18 is 
database language statement that corresponds to a query coupled, an instance of database interface 20 is generated by 
command (Block 144). For example, a GET OID command 45 the operating system and storage within object repository 18 
causes interface 20 to place the object identifier (OID) in a is allocated. An identifier for database 20 is returned to the 
proprietary database language statement that corresponds to application program. If application program 14 does not 
the GET command. If the query command uses a data value execute on the same process computer to which object 
or range of data values to identify the object or objects being repository 18 is coupled, the programming statement 
sought by the query, the data values are incorporated in a 50 requesting generation of an instance of database interface 20 
proprietary database language statement that corresponds to is transmitted to a component model executing on the 
the query (Block 146). The proprietary database language computer to which object repository 18 is coupled. The 
statement is then submitted to the database management request for an instance of interface 20 is provided to the 
system for the database implementing object repository 18 operating system and an instance of interface 20 is gener- 
(Block 150), Preferably, for JAVA class applications, the 55 ated. Again, the identifier of the instance of the interface is 
proprietary statements are provided to the database manage- provided through component model 80 to the requesting 
ment system for the Berkeley DB using a created instance of application program 14. Thereafter, object repository state- 
the data object com.sleepycat.db.Dbt provided with the ments in application program 14 are transferred to interface 
Berkeley DB that supports Java APIs. The created instance 20 for processing. Interface 20 generates data about data 
of the data object encapsulates the data for transfer to/from 60 objects so the serialized data of the object may be stored in 
repository 18 and delegates memory management for stor- repository 18 and queries are converted to the proprietary 
age of the object to the Berkeley DB. This is particularly query language supported by the database management 
advantageous for applications written as Java classes as Java system for repository 18. Responsive data are returned in 
does not support memory management and this task may be object data form to application program 14. Prior to 
delegated to the Berkeley DB. Additionally, the Berkeley 65 termination, application program 14 closes its connection to 
DB allows duplicate keys to be used so the object repository object repository 18 and the instance of interface 20 with 
supports one-to-many relationships. If object repository 18 which it communicated. 
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While the exemplary embodiment has been described in 
considerable detail, the applicant does not intend to restrict 
or in any way limit the scope of the appended claims to such 
detail. Additional advantages and modification will readily 
appear to those skilled in the art. The invention's broader 
aspects are therefore not limited to the specific details, 
representative apparatus and method, or illustrative 
examples shown and described. Accordingly, departures 
may be made from such details without departing from the 
scope or spirit of applicant's general inventive concepts. 

What is claimed is: 

1. A method for storing objects in an object repository 
comprising the steps of: 

storing an object identifier and a representation of the 

object in a first hash table; and 
storing data about the object as a key for the object 

identifier in a first hash table pair organized as a 

mirrored pair. 

2. The method of claim 1, the storing data about the object 
step further comprising the steps of: 

generating the object identifier for the object; 
determining a class name for the object; and 
using the class name as a key for storing the object 

identifier in a non-inverse table of the hash table pair 

organized as a mirrored pair. 

3. The method of claim 2 further comprising the step of: 
using the object identifier as a key for storing the class 

name in an inverse table of the hash table pair orga- 
nized as a mirrored pair. 

4. The method of claim 1, the storing representative data 
step further comprising the steps of: 

serializing the data representative of said object; and 
storing said serialized object data in the hash table with 
said object identifier as a key. 
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5. The method of claim 3 further comprising the steps of: 
determining names of methods for the object, the return 

types for the identified methods, and the data values 
returned by the identified methods; and 
using the method names, return types and returned data 
values as keys to store the object identifier in a non- 
inverse table of a second, third and fourth mirrored 
table pairs. 

6. The method of claim 5 further comprising the step of: 
3 using the generated object identifier as a key to store the 

method names, return types and returned data values in 
an inverse hash table of the second, third and fourth 
mirrored table pairs. 

7. A system for providing an object repository compris- 
S ing: 

a first hash table for storage of an object identifier as a key 
for data representative of an object identified by said 
object identifier; and 

3 at least one mirrored pair of hash tables, said mirrored pair 
of hash tables having a non-inverse hash table in which 
keys formed from data about the object are used to store 
the object identifier and an inverse hash table in which 
the object identifier is used as a key to store the data 

5 about the object. 

8. The system of claim 7 wherein said data about said 
object is one of a class name, method name, return type and 
a returned data value. 

9. The system of claim 7 further comprising a plurality of 
3 mirrored table pairs, each mirrored table pair having a 

non-inverse table in which data about the object is used to 
store the object identifier for the object and an inverse table 
in which the object identifier is used a key to store the data 
about the object. 

***** 
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